團隊開始依賴 AI coding 工具後，很容易養成一個錯覺：模型只是 IDE 裡的偏好設定，哪個不能用，換一個就好。

真的碰到模型退場，事情通常沒這麼乾脆。替代模型可能還沒被組織政策開放，也可能缺少原本工作流程依賴的 tool use、結構化輸出或 context 容量。畫面上選得到，只能證明選單有這個名字，不能證明工作接得起來。

GitHub Copilot 已排定多個模型在 2026-09-01 退場，並提醒 Copilot Enterprise 管理者，替代模型可能得先在 model policies 裡啟用。Google 的 Code Assist release notes 則記錄另一種切換：官方列出的個人使用者，以及 Google AI Pro、Google AI Ultra 方案使用者，自 2026-06-18 起已不能再透過原有 IDE extensions／CLI 發送服務請求，必須依方案遷移。

兩個案例的產品範圍不同，卻暴露同一個工程缺口：我們 pin 住了模型名稱，卻沒有寫下這個模型替團隊完成什麼工作。

下拉選單不是 dependency manager

一般相依套件升級，至少還看得到版本、changelog、測試結果與 rollback 方式。模型切換常只剩一則公告和一個新的選項，然後大家各自在 IDE 裡按下去。

這種切法省了幾分鐘，代價是沒有人能回答幾個很實際的問題：新模型能不能呼叫既有工具？輸出還守不守 schema？碰到權限拒絕時會停下來，還是換一條路繼續做？延遲與用量會不會超過原本預算？

官方列出的替代模型，只代表廠商提供了遷移方向。它不等於能力、品質、價格或組織可用性完全相同。團隊該管理 task-level capability contract，把「喜歡哪個模型」留在個人偏好設定裡。

先寫工作契約，再填模型名稱

我會先按任務分類寫必需能力。例如 frontend-release 需要讀寫 repository、執行測試、產生固定格式的 release record；高風險操作則必須保留人工核准。模型 ID 放在實作欄位，不能反過來定義需求。

下面這份 pseudo-YAML 由團隊自己維護，與 GitHub、Google 或其他廠商的官方設定格式無關：

task_class: frontend-release
required_capabilities:
  - repository_read_write
  - shell_tool
  - structured_output
  - explicit_permission_denial

constraints:
  latency_p95_seconds: 180
  usage_ceiling: "team-defined budget"

primary: current-model-id
fallback: candidate-model-id
policy_owner: platform-team
sunset_at: 2026-09-01T00:00:00Z
acceptance_fixture: fixtures/frontend-release-v3.md
evidence_path: artifacts/model-migration/frontend-release/
rollback_rule: "missing required tool or failed E2E => restore previous route"

YAML 只是載體。owner、fixture 與 rollback 有了明確落點，模型退場通知出現時，平台團隊知道誰要先檢查組織政策；開發團隊也知道該拿哪個固定案例驗收，不必靠「我用起來好像差不多」。

切換要走六步，不要直接 promote

我會把遷移拆成一條很短的流程：

1. inventory：找出舊模型綁定的任務、prompt、工具權限、配額與自動化路由。
2. enable alternative：由 policy owner 確認候選模型在組織內真的可用，權限也符合任務需求。
3. shadow run：用同一份 fixture 執行候選模型，但不讓它寫入 production，也不觸發重複部署。
4. compare evidence：比較 diff、指令紀錄、測試、結構化輸出與失敗路徑，不比較文風，更不要求不可觀察的推理過程。
5. promote：必需能力與 deny path 都通過後，才更新正式路由；高風險任務繼續保留人工核准。
6. remove old path：過了觀察與回退期限，再移除舊模型 ID、臨時 fallback 和過期文件。

這裡的 fallback 也要接受同一套驗收。API call 成功只是連線測試；組織政策尚未開放，或關鍵工具不存在時，這條 fallback 根本接不了工作。

用一個前端上線 fixture 把差異逼出來

假設團隊每週都要完成一個小型前端發版：調整 responsive card、跑 unit test 與 E2E，最後準備一張 Instagram 發布素材。這是一個很適合固定下來的 acceptance fixture，因為它同時碰到程式修改、工具執行與產出物交付。

同一份 fixture 交給舊模型與候選模型，各自留下：

• 實際套用的 patch，以及未完成的項目；
• 執行過的 command、exit code 與測試報告；
• 結構化 release record；
• 發布素材的檔案尺寸、格式與 evidence path；
• 權限遭拒、工具缺失或測試失敗時採取的停止與回復動作。

素材內容可以由模型協助產生，但固定尺寸輸出最好拆成 deterministic step。這個 fixture 裡，我會把產出的圖片交給 Resize Image for Instagram 在瀏覽器本機輸出指定版型，驗收程式只檢查最後 artifact 的尺寸與格式。這樣換模型時，不會把創作差異誤判成圖片處理能力退化。

fixture 刻意保持小而且能重複跑。只要輸入、允許的工具、預期產出與失敗條件固定，就能看出候選模型到底在哪一段偏離契約。

哪些情況應該停止切換

候選模型通過 happy path 還不夠。只要組織 policy 不可用、必要工具缺失、輸出破壞既有 schema，或失敗後無法回復，遷移就該 fail closed。保留舊路徑；若舊路徑已接近退場日，則縮小 task scope，先把高風險動作交回人工處理。

這聽起來比在下拉選單換名字麻煩，但它把麻煩放在還能控制的時間點。等舊模型真的消失才臨時試新模型，團隊只剩事故處理，根本沒空好好驗證相容性。

我不在乎團隊半年後還是不是用同一個模型。只要每次切換前，都能重新證明工作契約成立；契約不成立時，系統也確實會停下來，這套 AI coding 工作流程才算能維護。

參考來源

• Upcoming August 2026 model deprecations in GitHub Copilot
• Gemini Code Assist release notes
• GitHub Copilot changelog